1. Related Applications
On even date herewith, the following related applications were filed: (1) "Authorization Mechanism For Transfer Of Program Control Or Data Between Different Address Spaces Having Different Storage Protect Keys" by A. Heller et al and (2) "Mechanism For Control Of Address Translation By A Program Using A Plurality of Translation Tables" by A. Heller et al.
2. Field Of The Invention
This invention relates generally to data processing systems and more particularly to program or data protection hardware and techniques.
3. Description Of The Prior Art
Any stored program data processing system that provides for multiprogramming, multiprocessing, virtual memories, or a supervisor program providing for a multiple virtual system must be concerned with the protection of data and/or programs from inadvertent or unauthorized use or modification. A widely published form of this protection is that described in connection with Multics which is an operating system developed primarily by Massachusetts Institute of Technology in cooperation with General Electric Company and others, and first implemented on a Honeywell 635 Computer. This technique has been recently described in U.S. Pat. No. 4,177,510. Another form of protection mechanism is disclosed in U.S. Pat. No. 4,038,645, assigned to the assignee of the present invention, and is descriptive of the technique utilized in the IBM Series/1 computer system.
A particular form of prior protection mechanism, more closely associated with the present invention, is that defined for the IBM System/370 series of data processing systems. The organizational and hardware/architectural aspects of the IBM System/370 are described in the "IBM System/370 Principles of Operation", Form No. GA22-7000-4, File No. S/370-01. In the IBM System/370, the basic form of data protection is accomplished by the storage protect keys associated with physical blocks of memory and associated with particular programs. This concept is disclosed and claimed in U.S. Pat. No. RE 27,251 entitled "Memory Protection System", Issued 12/21/71 to G. M. Amdahl et al, and assigned to International Business Machines Corp. A four-bit coded storage protect key associated with physical blocks of memory is compared with a PSW key associated with a program to control access to data. In present IBM System/370 systems, the method by which programs are controlled in their access to data or the ability to call other programs in the data processing system is under strict control of an operating system or supervisor. One such control program is the Multiple Virtual System (MVS) control program. One program can call another program only by alerting the supervisor program by means of a Supervisor Call instruction (SVC), leaving to the supervisor program the determination of the authorization of the calling program to call the called program.
A major IBM System/370 user requirement addressed by this invention is to provide an enhanced method of communication between address spaces in a system operating under MVS. In present systems, there are a number of multi-address space program subsystems, e.g. IMS, TSO/VTAM, VSPC, and JES. These subsystems use a multiple address space structure to separate themselves from their users. This separation provides them with a number of advantages.
By providing their own address space in which to run their programs and keep their private data, they are able to better ensure a recovery environment for their programs and data. If users of the subsystem were to run in the same address space as the subsystem control, the subsystem's recovery could be affected by the user's recovery. If the subsystem's control information is kept in common storage, storage protect keys become the only mechanism to protect the data. However, there are not enough keys (16) to guarantee that the information is protected from an inadvertent store by another subsystem or authorized program since it is commonly addressable.
By using their own private area for keeping their control information, subsystems are able to have up to eight megabytes of addressability for their data. If more than eight megabytes of data is required, the subsystem may use more than one private address space for the data; in effect, extending the 24-bit addressability limit of the 370 architecture. By keeping sensitive data in their own private address space they are able to isolate their data from all unauthorized users in the system.
These are some of the reasons that subsystems use a multi-address space structure; however, there are problems with the communication mechanisms available in MVS for calling programs in another address space and moving/referencing data between two address spaces.
To permit calling of programs or reference data in another address space, the user must be authorized; therefore, most subsystems must embed the mechanisms within Supervisor Call instructions (SVC) to give an interface to the unauthorized user. Solutions require the user to do his own synchronization if a synchronous call is desired and are extremely slow.
Since the 370 architecture supports only one address space at any instant in time, subsystems must put any data that must be shared or moved between the subsystem and its user in common storage. This has a number of undesirable effects. The amount of common storage available for other uses is reduced because it is being used by only a few address spaces. Since the data is globally addressable in all address spaces, the only means of protecting the data against an inadvertent store is through keys. However, there are only sixteen keys, thus no guaranteed way of limiting access to the data can be ensured. If the data contains proprietary information, the only way to protect the security of the data is to fetch protect the data. Opportunities to exploit virtual storage such as virtual data bases are severely limited. If a virtual data base is to be shared among two or more users, the data base must be placed in common storage or the performance benefit of the virtual data will be negated by the slow private-to-private access mechanisms available. However, common storage is a limited resource; therefore virtual data bases must be relatively small.